A file server is a computer that provides file service relating to the organization of information on writeable persistent storage devices, such as memories, tapes or disks. The file server or filer may be embodied as a storage system including a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on, e.g., the disks. Each “on-disk” file may be implemented as set of data structures, e.g., disk blocks, configured to store information, such as the actual data for the file. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
One type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block on disk is retrieved (read) from disk into memory and “dirtied” with new data, the data block is stored (written) to a new location on disk to thereby optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. An example of a write-anywhere file system that is configured to operate on a storage system, such as a filer, is the Write Anywhere File Layout (WAFL™) file system available from Network Appliance, Inc., Sunnyvale, Calif. The WAFL file system is implemented as a microkernel within an overall protocol stack of the filer and associated disk storage.
The disk storage is typically implemented as one or more storage “volumes” that comprise a cluster of physical storage devices (disks), defining an overall logical arrangement of disk space. Each volume is generally associated with its own file system. In the WAFL file system, a special directory, called a “qtree”, may be created that has the properties of a logical sub-volume within the namespace of a physical volume. As used herein, a volume is a unit of storage comprising a file system or hierarchy of directories and files, and a qtree is a special directory similar to a mini-volume (mini-file system) or subdivision of a volume. Each file system object (file or directory) is associated with one and only one qtree, and quotas, security properties and other items can be assigned on a per-qtree basis. Each volume has its own file system identifier (ID) and each qtree within a volume has its own qtree ID.
A storage system may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access an application service executed by a server, such as a file server. In this model, the client may comprise an application executing on a computer that “connects” to the file server over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN) or virtual private network (VPN) implemented over a public network, such as the Internet. Network addresses, represented as alphanumeric computer names (such as URLs) or numeric addresses (such as Internet Protocol (IP) addresses), are often used as source and destination identifiers for communications among the clients and servers in a network. Each client may request the services of a file system on a file server by issuing file-system protocol messages (in the form of packets) to the network address of the server. It should be noted, however, that the file server may alternatively be configured to operate as an assembly of storage devices that is directly-attached to a (e.g., client or “host”) computer. Here, a user may request the services of the file system to access (i.e., read and/or write) data from/to the storage devices. The set of data accessible from a server comprises its data set.
Typically, a storage system, such as a filer, participates in a security domain that performs, inter alia, naming and authentication functions. Members of the security domain share security information, which may include authorized user and group identifiers (“security objects”). A user with an account in a particular security domain can log onto and access his or her account from any server in the domain. Generally, one server can be in one security domain (for each file-system protocol) at a time. For example, a filer in a Windows-based environment may be in an NT4 domain for Common Internet File System (CIFS) access, whereas another filer in a Unix-based environment may be in a Network Information System (NIS) domain for Network File System (NFS) access. However, in some network architectures, it may be advantageous for a server to simultaneously participate in multiple, protocol-specific security domains. For instance, it may be desirable to configure a server to participate in a MS domain for Unix clients and protocols and in an NT4 domain for Windows clients and protocols.
Multi-protocol servers may be implemented using server consolidation techniques. Server consolidation is thus defined as the ability to provide many logical or virtual servers within a single physical server platform. Prior server consolidation solutions are configured to run multiple instances of a process, such as an application service. Other server consolidation solutions provide many independent servers that are essentially “racked together” within a single platform. Examples of virtual servers embodied within a single platform are web servers, database servers, mail servers and name servers.
Thus, a multi-protocol server may be embodied as a plurality of protocol-specific logical servers, each participating in a different security domain. However, conventional multi-protocol servers do not support multiple logical servers that implement the same file-system protocol in different security domains. For example, a multi-protocol server may implement a logical server in an NT4 domain for CIFS requests and implement a different logical server in a NIS domain for NFS requests. Yet, problems typically arise if the multi-protocol server simultaneously implements two logical servers for, e.g., CIFS requests in different security domains, such as NT4 and NT5.
These problems may manifest themselves in various ways, depending on the configuration of the multi-protocol server. For example, assume two logical servers on a conventional filer attempt to process NFS requests in different security domains (e.g., NIS and NIS+). Firstly, the filer may not be able to determine to which logical server a received NFS request should be transferred. In other words, the received request may not identify in which security domain the request was sent. Secondly, if the security domains implement similar naming and authentication schema, conflicts may occur if each of the domains assigns the same security object (e.g., user or group identifier) to different files in the filer's data set. Thirdly, another problem may arise when “non-coordinating” administrators in the different domains set or change the on-disk security of files in the data set in a manner consistent with one security domain and not the other.
Because servers are generally not configured to simultaneously implement different security domains for a common file-system protocol, a protocol-specific server cannot participate in an old security domain and a new, updated security domain at the same time. However, information technology (IT) organizations frequently need to move their computer systems from one security domain to another, either due to changes in the IT infrastructure or due to richer functionality available in a newer type or version of naming and authentication software. Therefore, in order to transition a protocol-specific logical server (i.e. that processes CIFS requests) from one security domain to another, IT personnel typically set up and test the new domain “off-line,” e.g. without any “live” users or traffic. Upon debugging the new domain software and implementation off-line, the IT personnel switch all production systems from the old domain to the new domain in a “single-stroke,” i.e., during a designated day or weekend.
The above-mentioned single-stroke procedure for transitioning a server system from an old security domain to a new domain may involve multiple cycles of upgrade and revert steps in order to detect and fix problems with the new domain. That is, some problems can only be detected after the new domain becomes available to users and traffic (i.e., “on-line”), so the IT personnel may repeatedly have to revert to the old security domain to fix newly observed problems. Thus, the downtime of these steps may be unacceptable. The revert steps also may be difficult to perform. Furthermore, the single-stroke method may be expensive with regards to hardware resources since many computer systems may need to be substantially duplicated during the off-line testing of the new environment.
When a file server is transitioned from one security domain to another, e.g., in a single-stroke, the IP address scheme in which the server participates may change as well. However, sometimes it is desirable to transition the server to a new IP address scheme without changing its security domain. As used herein, an address scheme is defined as a set of rules that govern the interpretation and routing of network addresses. For example, networks configured for different IP address schemes may implement (i) different routing tables for a common range of IP addresses, (ii) a common routing table for different ranges of IP addresses, or (iii) different routing tables each having its own associated (possibly overlapping) range of IP addresses. Hereinafter, a range of IP addresses used in a network will be referred to as an IP address space.
A file server may be transitioned, e.g., by a system administrator, from one IP address scheme to another when organizational structure changes or the addition of new sub-networks necessitate reassignment of network addresses to clients and servers. Previously, the single-stroke method is used to configure network addresses, e.g. IP addresses, and other routing information off-line for those systems that change to a new IP address scheme. As when transitioning between security domains, the single-stroke method for changing IP address schemes may consume an unacceptable amount of time and resources.